Thanks for tackling this — the /api/phoenix returning 299 is a real issue. A few things need addressing before this can merge:

Blocking

1. Nil pointer panics in response parsing

item.DisplayCategories.Primary.Value will panic if either DisplayCategories or Primary is nil. Needs defensive checks:

if item.DisplayCategories != nil && item.DisplayCategories.Primary != nil {
    device.Type = item.DisplayCategories.Primary.Value
}

Same applies to result.Data.Endpoints.Items — if the GraphQL response structure differs from expected, the whole thing crashes silently or panics.

2. EntityID overwrite logic is unclear

device.EntityID = item.EndpointID  // set here first
// ...
if item.LegacyAppliance != nil {
    device.EntityID = item.LegacyAppliance.EntityID  // then overwritten here
}

If these IDs differ, which one does ControlSmartHome() actually need? This needs a comment explaining the precedence, or validation that they match.

3. Control endpoint silently changed

// Before:
_, err := c.request("PUT", "/api/phoenix/state", payload)

// After:
_, err := c.requestAlexa("PUT", "/api/phoenix/state", payload)

This switches the control endpoint from pitangui.amazon.com to alexa.amazon.com. If the control API doesn't exist at that host, all smart home controls break. Can you confirm device control still works after this change? This should probably be a separate PR or at least called out explicitly.

4. Reachable hardcoded to true

device.Reachable = true  // always true unless NetworkState parses

If LegacyAppliance is nil or NetworkState unmarshaling fails silently, every device appears online. The old endpoint returned reachability directly — this is a regression.

Questions

• What's the source for the GraphQL query structure? (mitmproxy capture, official docs, etc.)
• Did you test device control (not just listing) after this change?
• Is the HTTP 299 a permanent API deprecation or could it be transient?

The approach is sound — just needs hardening before it's safe to merge.